Vehicle health check via noise and vibration level

ABSTRACT

Technical solutions are described for autonomously monitoring health of a vehicle, such as a car, a truck and so on. An example computer-implemented method includes receiving sensor data of the vehicle. For example, the sensor data includes vibration data and microphone data. The vibration data measures vibration experienced by an occupant of the vehicle. The microphone data measures noises experienced by the occupant, including noises emanated by the vehicle. The method further includes accessing a predetermined performance data of the vehicle and determining a difference in the received sensor data and the predetermined performance data. The method further includes transmitting a notification of condition of the vehicle in response to the difference surpassing a predetermined threshold.

TECHNICAL FIELD

The present disclosure relates to vehicle health monitoring, and moreparticularly to analyzing a vehicle's health based on noise andvibration sensors of the vehicle.

BACKGROUND

Noise and vibration of a vehicle, such as automobiles and trucks, mayinclude interior noise and vibration characteristics, and exterior noiseand vibration characteristics. The internal noise and vibrationcharacteristics include noise and vibration experienced by occupants ofa cabin of the vehicle, while the exterior noise and vibrationcharacteristics are concerned with the noise and vibration radiated bythe vehicle, such as drive-by noise. The exterior noise performanceissues can also generate undesirable interior noise and vibration forthe occupants, for example, a damaged or degraded exhaust system,because of a hole in the muffler, generates noise and vibration concernsinside the vehicle. The noise and vibration of the vehicle may affectsatisfaction of the occupants, such as the driver and passenger, and inturn affect the ownership experience of the vehicle

SUMMARY

According to one or more exemplary embodiments, a computer-implementedmethod for autonomously monitoring health of a vehicle includesreceiving a vibration data of the vehicle, where the vibration dataincludes measurements of vibration experienced by one or more componentof the vehicle. The computer-implemented method also includes accessinga predetermined vibration performance data of the vehicle. Thecomputer-implemented method also includes determining a difference inthe received vibration data and the predetermined vibration performancedata. The computer-implemented method also includes transmitting anotification of a condition of the vehicle in response to the differencesurpassing a predetermined threshold.

According to one or more exemplary embodiments, an apparatus forautonomously monitoring health of a vehicle includes a memory, acommunication interface, and a processor communicably coupled with thememory and the communication interface. The processor receives vibrationdata of the vehicle, where the vibration data includes measurements ofvibration of one or more components of the vehicle. The processor alsoaccesses a predetermined vibration performance data of the vehicle. Theprocessor also determines a difference in the received vibration dataand the predetermined vibration performance data. The processor alsotransmits a notification of a condition of the vehicle in response tothe difference surpassing a predetermined threshold.

According to one or more exemplary embodiments, a computer-programproduct for autonomously monitoring health of a vehicle includes acomputer readable storage medium, where the computer readable storagemedium includes computer executable instructions to receive vibrationdata of the vehicle, where the vibration data includes measurements ofvibration experienced by an occupant of the vehicle. The computerreadable storage medium further includes instructions to access apredetermined vibration performance data of the vehicle. The computerreadable storage medium further includes instructions to determine adifference in the received vibration data and the predeterminedvibration performance data. The computer readable storage medium furtherincludes instructions to transmit a notification of a condition with thevehicle in response to the difference surpassing a predeterminedthreshold.

The above features and advantages and other features and advantages ofthe invention are readily apparent from the following detaileddescription of the invention when taken in connection with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features, advantages and details appear, by way of example only,in the following detailed description of embodiments, the detaileddescription referring to the drawings in which:

FIG. 1 illustrates an example of an autonomous health check system for avehicle;

FIG. 2 illustrates example components of an autonomous health checksystem for a vehicle;

FIG. 3 illustrates a flowchart of an example method of autonomouslymonitoring the health of a vehicle;

FIG. 4 illustrates an example comparison of sensor data andpredetermined performance data for autonomously monitoring the health ofa vehicle; and

FIG. 5 illustrates a flowchart of an example method for autonomouslydiagnosing a problem detected by a vehicle health check system.

DETAILED DESCRIPTION

The following description is merely exemplary in nature and is notintended to limit the present disclosure, its application, or uses. Itshould be understood that throughout the drawings, correspondingreference numerals indicate like or corresponding parts and features. Asused herein, the term module refers to processing circuitry that mayinclude an application specific integrated circuit (ASIC), an electroniccircuit, a processor (shared, dedicated, or group) and memory thatexecutes one or more software or firmware programs, a combinationallogic circuit, and/or other suitable components that provide thedescribed functionality.

The technical solutions described herein facilitate an autonomous healthcheck of a vehicle, such as an automobile, a truck, a boat, or any othervehicle. The vehicle may be an autonomous vehicle, a partiallyautonomous vehicle, or a non-autonomous (human-controlled) vehicle. Theautonomous health check includes monitoring and analyzing a noise andvibration status of the vehicle for diagnosing and detecting aperformance issue, or condition with the vehicle. The autonomous healthcheck facilitates detecting and analyzing noises such as a road noise, awind noise, a powertrain noise, a squeak noise, a rattle noise, and/orother such different types of noises. For example, the noise(s)experienced in the vehicle and/or emanated by the vehicle may berecorded, such as using microphones or any other audio capturingapparatus. The autonomous health check further includes detecting andanalyzing vibration levels of the vehicle. For example, the vibrationexperienced by an occupant of the vehicle, or one or more components ofthe vehicle, may be recorded using vibration-sensing apparatus, such asaccelerometers, gyroscopes, position sensors, displacement sensors, orany other sensors. The autonomous health check facilitates detectingthat the vehicle's noise and/or vibration performance level hassurpassed a predetermined threshold. For example, surpassing thepredetermined threshold indicates a degradation of performance of thevehicle or one or more components of the vehicle. The predeterminedthreshold(s) may be based on a type of the vehicle and further may beconfigured for the specific vehicle. For example, a customer may changethe predetermined threshold performance level with which the noise andvibration measurement data from the vehicle is compared. For example, incase the customer is a fleet manager/owner, the customer may have apredetermined performance level set for each vehicle in a fleet ofvehicles. Alternatively or in addition, for example, if the customer isan owner of a single vehicle, the customer may use a specificperformance level according to the customer's preference. Alternativelyor in addition, the manufacturer of the vehicle may setup thepredetermined threshold levels of the vehicle.

In case the autonomous health check system determines that the recordednoise and vibration measurements indicate a degraded performance of thevehicle, the autonomous health check may transmit a notification of theproblem. The notification may be transmitted to the operator, such asmanager/owner of the vehicle. Alternatively or in addition, theautonomous health check system may transmit a notification to thevehicle that causes the vehicle to proceed to a service facility. Forexample, in case the vehicle is part of an autonomous fleet thenotification facilitates the fleet manager/owner to prevent selection ofa specific vehicle for use if the vehicle is associated with degradednoise and vibration performance. Alternatively or in addition, thecustomer may be notified of needed service. Thus, in case of a fleet ofvehicles, such as a fleet of autonomous vehicles, or rental vehicles,(wherein an occupant, such as a renter, is not assured the same vehiclefor each use) the technical solutions described herein facilitate theoccupant to experience a consistent performance level of the vehicle.For example, the fleet owner/manager may specify a branded noise andvibration performance for each vehicle in a fleet. The consistentexperience across the fleet facilitates the fleet owner/manager to avoidpotential customer dissatisfaction by preventing vehicles with degradedperformance from remaining in service.

Alternatively or in addition, if the vehicle is an autonomous vehicle,the transmission of the notification may cause the vehicle to navigateautonomously to a service station. Alternatively yet, in response to thenotification of a degraded noise and vibration performance of thevehicle, the customer may determine a designated route for the vehicleto minimize exposure to additional degradation of the vehicle'sperformance.

An autonomous health check system may check the health of the vehicle asdescribed herein. The autonomous health check system may be installed inthe vehicle itself, or may be at a remote location. For example, theautonomous health check system may include a server that receives sensormeasurements, such as the noise and vibration measurements, recorded inthe vehicle. The vehicle may be equipped with the sensors, which maytransmit the recorded data to the server. Alternatively or in addition,the autonomous health check system may include a controller equipped inthe vehicle that accumulates the measurements from the sensors in thevehicle, and transmits the measurements to the server for furtheranalysis for diagnosing the health status of the vehicle. Alternativelyor in addition, the controller in the vehicle may analyze the recordedmeasurements for diagnosing the health of the vehicle. The autonomoushealth check system may further include the sensors used to record themeasurements of the vehicle. For example, the sensors may includeaccelerometers, microphones, gyroscopes, inertia measurement devices,displacement or force transducers, or any other sensors. The sensors maybe located in specific positions in and/or out of the vehicle. Thesensors may be tailored for diagnosing specific noise and vibrationperformance levels that are associated with degraded performance of thevehicle. For example, the sensors may include microphones that arelocated to detect degraded powertrain isolation or elevated soundpressure levels, such as noise, which may be caused by road, wind,components of the vehicle, or a combination thereof. Alternatively or inaddition, the sensors may include sensors that are located to detectvibration due to mechanical issues, such as a powertrain malfunction, atransmission malfunction, a tire failure, or a malfunction of any othercomponent of the vehicle requiring inspection. The powertrain may bepowered by gasoline, diesel, electric, fuel cell, or a combinationthereof. The component of the vehicle requiring inspection may be anelectrical, mechanical, or electro-mechanical component, such aselectrical pump, motor, actuator, or other component that causes noiseand/or vibration.

FIG. 1 illustrates an example of a health check system 150 that analyzesthe health of a vehicle 110. The health check system 150 may beautonomous, that is it may operate without human intervention, such asin a preprogrammed manner. For example, the health check system 150receives sensor data from a sensor controller 130. The sensor controller130 may transmit the sensor data recorded by sensors 120. The healthcheck system 150 analyzes the sensor data, such as by comparing withpredetermined performance data, to diagnose if the vehicle 110 requiresinspection, such as a degradation of performance. Based on the analysis,the health check system 150 transmits a notification to a notificationapparatus 160.

The vehicle 110 may be any vehicle such as an automobile (for example, acar, and a truck), a boat, an all-terrain vehicle, or any other type ofvehicle. The vehicle may further be classified according to a size ofthe vehicle, such as a full-size vehicle, a mid-size vehicle, a compactvehicle, or any other categorization. The vehicle 110 may further beclassified according to features of the vehicle 110, such as a basemodel vehicle, mid-level model vehicle, a high-level model vehicle, aluxury model vehicle, and so on. Of course, other categorization of thevehicle 110 is possible as will be understood by a person skilled in theart.

The sensors 120 include one or more sensors of different types. Forexample, the sensors 120 include one or more vibration sensors, whichmeasure vibration performance data of the vehicle 110. For example, thevibration sensors may be accelerometers, which measure the vibration bymeasuring proper acceleration (“g-force”). Each accelerometer maymeasure the corresponding proper acceleration along one or more axes, X,Y, and/or Z. The accelerometer may measure magnitude and direction ofthe proper acceleration as a vector quantity, and thus may provideorientation data of the vibrations experienced by the accelerometer. Thesensors 120 are located inside/outside the vehicle so as to detectvibrations proactively before an occupant of the vehicle experiences thevibration. For example, the vibration detected by the sensors 120 may besmaller than a level that a human occupant may be able to detect, andthus provide an early detection of the condition with the vehicle 110.For example, the vibration sensors may be located on the seat tracks ofthe vehicle 110, thus detecting a vibration experienced by an occupanton respective seats. Alternatively or in addition, the vibration sensorsmay be in communication with the seat tracks. The vibration sensors maybe in communication with any of the one or more seat tracks of thevehicle 110. For example, the vibration sensors may be in communicationwith driver's seat track, the front passengers' seat track, or a rearpassenger's seat track. The vibration sensors may further be located todetect vibrations along a steering column of the vehicle, for examplelocating the vibration sensors on the steering wheel, or the steeringwheel column. Alternatively or in addition, the vibration sensors may bein communication with the steering column. The vibration sensors maydetect vibrations experienced by the occupants because of a degradationof a vehicle system or components including but not limited to tire andwheel, suspension, steering, powertrain, driveline, or any othercomponent of the wheel assembly.

The sensors 120 may further include sound pressure measuring sensors,such as microphones, which convert sound pressure levels into electricalsignals. The microphones may record sound from inside and/or outside acabin of the vehicle 110. In the present disclosure inside the vehicle,or cabin, refers to the seating area of the vehicle 110, where the oneor more occupants of the vehicle are seated when operating the vehicle.The sensors 120 include sensors, which may be located inside the cabin,as well as sensors, which may be located outside the cabin. For example,one or more of the microphones may be located inside the cabin, such asin proximity to an ear of the one or more occupants. For example, one ormore microphones may be in communication with a seat, or located on aseat, such as at the top, or a predetermined distance from, one of thetop edges of the seat or in a headrest. Such a microphone may recordsound that an occupant of the vehicle may experience. Additionally oralternatively, the sensors 120 include microphones that are incommunication with, or located near other components inside the vehicle,such as a rearview mirror, the steering wheel, the gearbox, or any othercomponent inside the cabin. The sensors 120 further include microphonesthat are in communication with, or located outside the cabin, such asnear the suspension system, tire, driveline, powertrain, under the hood,or any other location of the vehicle.

The health check system 150 analyzes the data from the sensors 120 toidentify and report vehicle performance data. For example, the one ormore vibration sensors may be located at a corner of the vehicle, suchas on a suspension or chassis related component. Such vibration sensorsmay facilitate detection of a tire related condition such as an out ofbalance tire, a flat tire, and degraded treads of the tire, amongothers. The vibration data may further facilitate monitoring of thesuspension system, such as a loss of road isolation, which may be causedby damaged or worn out suspension and/or chassis related isolationmechanisms (bushings, ball joints, mounts, absorbers etc.) or cradlebushings. The vibration data may alternatively, or in addition,facilitate detection of conditions associated with a chassis,powertrain, driveline, or any other component of the vehicle 110. Forexample, the vibration data may facilitate detection of a loss ofpowertrain or driveline isolation, which may be caused by damaged orworn out powertrain mounts or bushings.

The sensor controller 130 may accumulate the data recorded by the one ormore sensors 120 and transmit them to the health check system 150. Thesensor controller 130 may be electronic circuitry, such as a processingunit coupled with memory and communication interface(s). The sensorcontroller 130 may communicate with the health check system 150 in awired or a wireless manner. In an example, the sensor controller 130 maybe part of the health check system 150, such as if the health checksystem is equipped on the vehicle 110. Alternatively, the health checksystem 150 may be remotely located, and the sensor controller 130 maytransmit the sensor data to the health check system 150 wirelessly, suchas via a Long-Term Evolution (LTE) network, or any other wirelessnetwork. The health check system 150 may be a cloud-based system. Thesensor controller 130 may communicate the sensor data using one or morecommunication protocols such as High Speed Packet Access (HSPA), or anyother communication protocol. The sensor controller 130 may accumulatethe sensor data from the one or more sensors 120 and store the sensordata for a predetermined duration, such as a day, a week, three months,six months, or any other duration. The sensor controller 130 may storethe sensor data in a data repository, which is accessible by the healthcheck system 150. In an example, the data repository may be part of thehealth check system 150.

Additionally or alternatively, the health check system 150 receives andanalyzes the microphone data from the vehicle 110. For example, thehealth check system 150 identifies a specific squeak, or rattle, fromthe data accumulated by the microphones. The health check systemadditionally, or alternatively, identifies wind noise, or rush issueswith the vehicle 110 from the accumulated microphone data. Further, thehealth check system 150 analyzes the microphone data to identify roadnoise such as booms (drumming), tones, and other such exterior noise.

While the health check system 150 may analyze the sensor data inisolation, such as analyzing vibration data separately from themicrophone (or noise) data, the health check system 150, in addition,may analyze the data from the different sensors 120 cumulatively. Forexample, the health check system 150 analyzes both the vibration dataand the noise data to identify booms, which may be low frequency orlow-pitched noise accompanied by vibration. The health check system 150may analyze the sensor data to identify different types of noise andvibration that an occupant of the vehicle 110 may experience when thevehicle 110 is in operation. The health check system 150 identifies andcategorizes the noise and vibration data to identify the differentperformance levels of the vehicle 110 autonomously. By continuouslymonitoring the performance levels of the vehicle 110 and by comparingthe performance levels with predetermined performance levels, the healthcheck system 150 proactively diagnoses degradation in the performance ofthe vehicle 110. In response to identifying degradation, the healthcheck system 150 notifies the notification apparatus 160 to facilitate aservicing of the vehicle 110. Additionally or alternatively, the healthcheck system 150 facilitates warning the driver/passenger/fleet owner ofthe vehicle 110.

The notification apparatus 160 may be a communication apparatus thatreceives the notification from the health check system 150. Thenotification apparatus 160 may be electronic circuitry that includes aprocessing circuitry, a memory, and a communication interface, amongother components. For example, the notification apparatus 160 may be aphone, a tablet computer, a laptop computer, a desktop computer, aserver computer, or any other communication apparatus. In an embodiment,the notification apparatus 160, upon receiving the notification from thehealth check system 150, prompts the owner/manager of the vehicle 110.The owner/manager of the vehicle 110 may or may not be an occupant ofthe vehicle. The vehicle 110 may be part of a fleet of vehicles that isowned/operated by an entity different from the occupant. For example,the vehicle 110 may be a rented, or a ride-share vehicle. Alternativelyor in addition, the vehicle 110 may be an autonomous vehicle that isrented or ride-shared. Accordingly, in such cases, the health checksystem 150 transmits the notification to the notification apparatus ofthe owner/manager as may be configured in the health check system 150.In case the owner/manager of the vehicle 110 is an occupant of thevehicle 110, the health check system 150 transmits the notification tothe owner/manager, who is also an occupant. The owner/manager, uponreceiving the notification may take the vehicle 110 to a servicefacility.

In another example, if the vehicle 110 is an autonomous vehicle, thenotification apparatus 160 may be a part of the vehicle 110. Thenotification apparatus 160 may communicate with a controller of theautonomous vehicle. In such a case, the health check system 150 notifiesthe notification apparatus 160 to cause the controller of the autonomousvehicle to navigate the autonomous vehicle to a service facility. Forexample, the health check system 150 may identify the nearest servicefacility, such as based on current location of the vehicle 110 and adata repository of service facilities. The health check system 150 mayprovide the service facility location (address, coordinates etc.) to thenotification apparatus 160 causing the autonomous vehicle to navigate tothe service facility. The health check system 150 may include theservice facility information even if the vehicle 110 is not anautonomous vehicle.

The health check system 150, thus, receives the sensor data from thesensor controller 130, analyzes the received sensor data, and notifiesthe notification apparatus 160 upon detecting a service issue. Thehealth check system 150 may send a status report to the notificationapparatus 160 even if a service issue is not detected. For example, thehealth check system 150 may send a periodic health report to thenotification apparatus 160, which includes diagnostic information of thevehicle 110. For example, the health check system 150 may send thehealth report every three months, every six months, every month, or atany other frequency. The health check system 150 may send the healthreport on demand, such as upon receiving a request for the healthreport. For example, the owner/manager of the vehicle 110, via thenotification apparatus 160, may send a request for the health report.The health check system 150, in response to the request, may accessaccumulated sensor data over a predetermined duration. Alternatively, orin addition, the health check system 150 requests the sensor controller130 to collect sensor data from the one or more sensors 120 forgenerating the health report. In an example, the health check system 150may access or request the sensor controller 130 to collect sensor datafrom a subset of the one or more sensors 120. For example, the sensorcontroller 130 may collect sensor data only from the sensors that arelocated in proximity to a driver seat in the vehicle 110, or only fromthe sensors inside the cabin of the vehicle 110, or only from thesensors outside the cabin of the vehicle 110.

Alternatively or in addition, the health check system 150 may access orrequest sensor data from a subset of sensors that are associated withspecific components of the vehicle 110. For example, the subset ofsensors may include one or more sensors associated with the seat tracks.The subset of sensors may include one or more sensors associated withthe powertrain. The subset of sensors may include one or more sensorsassociated with the driveline. The subset of sensors may include one ormore sensors associated with the tires. The subset of sensors mayinclude one or more sensors associated with the suspension, or any othersuch components of the vehicle 110. The sensor data from the subset ofsensors that are associated with specific components may be analyzedalong with one or more of the vibration data and the microphone data todiagnose a vehicle condition and provide a notification regarding thediagnosed vehicle condition.

FIG. 2 illustrates example components of the health check system 150.The health check system 150 may be a communication apparatus, such as acomputer. For example, the health check system 150 may be a desktopcomputer, a tablet computer, a laptop computer, a phone, such as asmartphone, a server computer, or any other device that communicates viaa network 265. Alternatively or in addition, the health check system 150may be a controller that controls the operation of an autonomousvehicle. The health check system 150 includes hardware, such aselectronic circuitry.

The health check system 150 includes, among other components, aprocessor 205; memory 210 coupled to a memory controller 215, and one ormore input devices 245 and/or output devices 240, such as peripheral orcontrol devices that are communicatively coupled via a local I/Ocontroller 235. These devices 240 and 245 may include, for example,battery sensors, position sensors (altimeter, GPS, and the like),indicator/identification lights, and the like. Input devices such as aconventional keyboard 250 and mouse 255 may be coupled to the I/Ocontroller 235. The I/O controller 235 may be, for example, one or morebuses or other wired or wireless connections, as are known in the art.The I/O controller 235 may have additional elements, which are omittedfor simplicity, such as controllers, buffers (caches), drivers,repeaters, and receivers, to enable communications.

The I/O devices 240, 245 may further include devices that communicateboth inputs and outputs, for instance disk and tape storage, a networkinterface card (NIC) or modulator/demodulator (for accessing otherfiles, devices, systems, or a network), a radio frequency (RF) or othertransceiver, a telephonic interface, a bridge, a router, and the like.

The processor 205 is a hardware device for executing hardwareinstructions or software, particularly those stored in memory 210. Theprocessor 205 may be a custom made or commercially available processor,a central processing unit (CPU), an auxiliary processor among severalprocessors associated with the health check system 150, a semiconductorbased microprocessor (in the form of a microchip or chip set), amacroprocessor, or other device for executing instructions. Theprocessor 205 includes a cache 270, which may include, but is notlimited to, an instruction cache to speed up executable instructionfetch, a data cache to speed up data fetch and store, and a translationlookaside buffer (TLB) used to speed up virtual-to-physical addresstranslation for both executable instructions and data. The cache 270 maybe organized as a hierarchy of more cache levels (L1, L2, and so on.).

The memory 210 may include one or combinations of volatile memoryelements (for example, random access memory, RAM, such as DRAM, SRAM,SDRAM) and nonvolatile memory elements (for example, ROM, erasableprogrammable read only memory (EPROM), electronically erasableprogrammable read only memory (EEPROM), programmable read only memory(PROM), tape, compact disc read only memory (CD-ROM), disk, diskette,cartridge, cassette or the like). Moreover, the memory 210 mayincorporate electronic, magnetic, optical, or other types of storagemedia. Note that the memory 210 may have a distributed architecture,where various components are situated remote from one another but may beaccessed by the processor 205.

The instructions in memory 210 may include one or more separateprograms, each of which comprises an ordered listing of executableinstructions for implementing logical functions. In the example of FIG.2, the instructions in the memory 210 include a suitable operatingsystem (OS) 211. The operating system 211 essentially may control theexecution of other computer programs and provides scheduling,input-output control, file and data management, memory management, andcommunication control and related services.

Additional data, including, for example, instructions for the processor205 or other retrievable information, may be stored in storage 220,which may be a storage device such as a hard disk drive or solid statedrive. The stored instructions in memory 210 or in storage 220 mayinclude those enabling the processor to execute one or more aspects ofthe systems and methods of this disclosure.

The health check system 150 may further include a display controller 225coupled to a user interface or display 230. In some embodiments, thedisplay 230 may be an LCD screen. In other embodiments, the display 230may include a plurality of LED status lights. In some embodiments, thehealth check system 150 may further include a network interface 260 forcoupling to a network 265. The network 265 may be an IP-based networkfor communication between the health check system 150 and an externalserver, client and the like, such as the notification apparatus 160 andthe sensor controller 130, via a broadband connection. In an embodiment,the network 265 may be a satellite network (i.e. OnStar). The network265 transmits and receives data between the health check system 150 andexternal systems. In some embodiments, the network 265 may be a managedIP network administered by a service provider. The network 265 may beimplemented in a wireless fashion, for example, using wireless protocolsand technologies, such as Wi-Fi, WiMAX, satellite, or any other. Thenetwork 265 may also be a packet-switched network such as a local areanetwork, wide area network, metropolitan area network, the Internet, orother similar type of network environment. The network 265 may be afixed wireless network, a wireless local area network (LAN), a wirelesswide area network (WAN) a personal area network (PAN), a virtual privatenetwork (VPN), intranet or other suitable network system and may includeequipment for receiving and transmitting signals.

The notification apparatus 160 and the sensors controller 130 may alsoinclude components similar to those illustrated in FIG. 2.

FIG. 3 illustrates a flowchart of an example method of autonomouslymonitoring the health of the vehicle 110. The health check system 150accesses sensor data associated with the vehicle 110, as shown at block310. For example, the sensor data may include vibration data and noisedata accumulated by the sensors 120 of the vehicle 110, as shown atblocks 312 and 314. For example, the health check system 150 accessesthe sensor data via the data repository in which the sensor controller130 stores the accumulated sensor data. Alternatively or in addition,the health check system 150 receives the sensor data from the sensorcontroller 130. Alternatively or in addition, the health check system150 receives the sensor data from the sensors 120 directly. The sensordata may additionally include a location at which the sensors 120collected the sensor data. For example, the sensor controller 130 mayadd the location information when storing the sensor data from thesensors 120. The sensor data may further include a timestamp thatidentifies the time at which the sensors collected the sensor data. Forexample, the sensor controller 130 adds the timestamp information to thesensor data collected by the sensor 120.

Table 1 illustrates example sensor data that includes a vehicleidentifier, a sensor identifier, a timestamp, a location, and a sensormeasurement, among other data in an entry of the sensor data. Thevehicle identifier is a unique identifier associated with the vehicle110, which the health check system 150 uses to differentiate the vehicle110 from other vehicles that the health check system 150 monitors. Forexample, the vehicle identifier may be a vehicle identification number(VIN) associated with the vehicle, or any other identifier that thehealth check system 150 generates for the vehicle 110. The sensoridentifier is a unique identifier associated with each sensor in thevehicle 110. The health check system 150 uses the sensor identifier todifferentiate a sensor from other sensors. The sensor identifier mayfurther identify a location of the corresponding sensor on the vehicle110. For example, a sensor located in the seat track may be identifiedby a first identifier (for example 1), while a sensor located in thesuspension system may be identified by a second identifier (for example,2). The identifiers may use a different format or scheme than theexample provided here. The timestamp and the location data in the sensordata may identify the time and location at which the correspondingsensor collected the sensor measurement.

The sensor data may have additional or fewer data elements than theexample in Table 1. In one or more examples, a data point in the sensordata, may include full vehicle CAN bus traffic, which includes data fromall sensors and systems on the vehicle 110. As such, it could bedetermined exactly what condition the vehicle was experiencing when thenoise and vibration data was recorded based on the CAN bus traffic. Forexample, if a large excursion was noted from an accelerometer, cameradata could be accessed to comprehend and help identify if the vehiclehit a large object to cause a failure of a component.

TABLE 1 Location Vehicle Sensor (Latitude, Sensor Identifier IdentifierTimestamp Longitude) Measurement XX1 S-1 (seat 2012 Oct. 3 40.71, −74.001.6 track) 03:00:03 XX1 S-2 (front 2012 Oct. 3 40.71, −74.00 3.1passenger 03:00:03 tire) XX1 S-3 2012 Oct. 3 40.71, −74.00 1.5(steering) 03:00:03

Referring again to FIG. 3, the health check system further accessespredetermined performance data associated with the vehicle 110, as shownat block 320. The health check system 150 accesses the predeterminedperformance data from a data repository, which may be the same datarepository that contains the measured sensor data. Alternatively or inaddition, the health check system 150 stores the predeterminedperformance data of the vehicle 110. Accessing the predeterminedperformance data may include the health check system 150 determining thevehicle identifier, as shown at block 322. The health check system 150may use the vehicle identifier to identify the type of vehicle 110, asshown at block 324. For example, the type of the vehicle 110 mayidentify the vehicle 110 as a luxury vehicle, a base model vehicle, asports vehicle, a compact vehicle, or any other type of vehicle. Thedifferent types of vehicle may have respective drive performance, andaccordingly respective performance data. For example, the luxury vehiclemay have a smoother ride, with lesser vibrations and/or noisetransmitted to the cabin for the occupants to experience, in comparisonto the base model. In one or more examples, the sports model may have aperformance data that facilitates a more sportier ride for the occupantsin comparison to the luxury vehicle. For example, the sports model mayhave specific noise performance data may include facilitate highervalues of noise of the vehicle 110 to be experienced by the occupantsthan the luxury vehicle, but a similar vibration data performance asthat of the luxury vehicle. It is understood that in other examples, theperformance data of the different types of vehicles may be differentthan the above listing. The health check system 150 further determinesthe performance data associated with the vehicle 110, as shown at block326. For example, the performance data may be identified using thevehicle identifier. Alternatively or in addition, the health checksystem 150 determines the performance data based on the type of thevehicle identifier. The predetermined performance data may includepredetermined vibration performance data, and may further includepredetermined noise performance data.

The health check system 150 compares the accessed sensor data and thepredetermined performance data, as shown at block 330 and comparessensor data collected by the sensors 120 of the vehicle 110 and thepredetermined performance data that is specifically associated with thevehicle 110. For example, the vibration data from the sensors 120 may becompared with the predetermined vibration performance data and the noisedata from the sensors 120 may be compared with the predetermined noiseperformance data. The predetermined performance data may be differentfor different vehicles. For example, the predetermined performance dataof a first vehicle, which may be a base model-type vehicle, may bedifferent from a second vehicle, which may be a luxury-type vehicle.Thus, the predetermined performance data may vary according to the typeof the vehicle 110.

In addition, or alternatively, the predetermined performance data mayvary according to vehicle type. For example, the owner/manager of thevehicle 110 may prefer a particular performance level from the vehicle110. The owner/manager may, accordingly, specify the predetermineperformance data for the vehicle 110. For example, the owner/manager ofa first vehicle may prefer a sportier driving experience and thevibration and noise performance data of the first vehicle may beconfigured accordingly. An owner/manager of a second vehicle may prefera smoother driving experience and the vibration and noise performancedata of the second vehicle may be configured accordingly; distinct fromthat of the first vehicle.

FIG. 4 illustrates an example comparison of the sensor data and thepredetermined performance data. In the illustrated example, the sensordata represented by curve 410 illustrates a degraded noise performance,indicating that the vehicle requires servicing. Further, curve 420represents the predetermined performance data that the gray coloredcurve 410 is compared with to identify that the servicing is required.While, FIG. 4 illustrates comparison of noise data and predeterminednoise data, a comparison of vibration data and predetermined vibrationdata can be performed in one or more examples.

The health check system 150, based on the comparison of the accessedsensor data of the vehicle 110 and the predetermined performance data ofthe vehicle 110, determines if the performance of the vehicle 110 hasdegraded, as shown at blocks 340 and 350. In case the performance hasnot degraded, that is, the vehicle 110 is operating at least at thepredetermined performance, the health check system 150 continuesmonitoring the health of the vehicle 110. The health check system 150may generate and transmit a health report that indicates that there isno problem detected with the performance of the vehicle 110. If thehealth check system 150 detects a degraded performance, the health checksystem 150 attempts to diagnose the problem of the vehicle, as shown atblock 350. The health check system 150 also determines a severity of thediagnosed problem, as shown at block 350. For example, differentproblems with the vehicle 110 maybe categorized into separate severitycategories. The categories may include a safety-related problemcategory. In case of a safety-related problem being detected, the healthcheck system 150 stops the vehicle 110, as shown at blocks 352 and 355.For example, if the vehicle 110 is an autonomous vehicle, the healthcheck system 150 transmits an executable instruction to the vehicle 110to move the vehicle to the closest safe-zone, such as a shoulder or aside of the road, and turn the vehicle 110 off.

The health check system 150 further transmits a notification to thenotification apparatus 160, as shown at block 360. The notification issent regardless of the severity level of the problem detected. In casethe vehicle 110 has been stopped due to a safety-related problem, thenotification may include a location at which the vehicle 110 wasstopped. The notification may include the diagnosis information. Thenotification may further include a location of one or more servicefacilities for servicing the vehicle 110. In addition, the notificationmay include severity information that may identify a functional safetyissue. For example, the notification may denote the problematiccondition of the vehicle as requiring immediate attention if the healthcheck system 100 identifies that the problematic condition raises asafety issue. The notification may denote the problematic conditionbeing not severe if the health check system 100 identifies that theproblematic condition raises a vehicle satisfaction condition.

FIG. 5 illustrates a flowchart of an example method for autonomouslydiagnosing the problem detected by the health check system 150. Thehealth check system 150 may use the method to diagnose the problem atblock 350 of FIG. 3. For example, the health check system 150, upondetecting that the performance of the vehicle has degraded in comparisonto the predetermined performance data, compares the sensor data withpredetermined sensor data associated with the vehicle 110, as shown atblock 510. The predetermined sensor data may include sensor data whenthe vehicle 110 was previously diagnosed with a service issue.Alternatively or in addition, the predetermined sensor data may includesensor data from other vehicles or simulated data that is indicative ofa specific service requirement of vehicle 110 or a component thereof.For example, the predetermined sensor data may include validated datathat is indicative of a tire, a suspension, a driveline, or a powertrainservice requirement. For example, the validated data may be measured atstrut top mounts, lower control arms, body or chassis structure, or anyother component of the vehicle 110. In one or more examples, theperformance data is stored locally on the vehicle 110 itself, andaccessible by the health check system 150. Alternatively or in addition,the predetermined sensor data may include sensor data indicative of ahealthy vehicle, which does not have any known problem. If thecomparison with the predetermined sensor data is indicative of a problemas described earlier, the health check system 150 identifies a specificproblem by comparing the sensor data with specific predetermined data asillustrated further in FIG. 5 and described below. It is understood thatthe specific problem detection may be performed sequentially or inparallel; in other words, the health check system 150 may analyze thesensor data for identifying a specific problem one at a time, or analyzethe sensor data to identify two or more specific problems concurrently.

In an exemplary embodiment, the health check system 150 determines ifthe sensor data is indicative of a tire service requirement as shown atblock 520. To this end, the health check system 150 analyzes the sensordata, including the vibration and/or noise data accumulated by the oneor more sensors that are associated with the tires of the vehicle 110.For example, as described herein, the health check system 150 identifiesthe subset of one or more sensors that are associated with the tires ofthe vehicle 110, based on the vehicle identifier and the sensoridentifier. The health check system 150 compares the sensor data fromthe identified subset of sensors with predetermined threshold dataassociated with the tires. If the predetermined threshold data issurpassed (above/below) the health check system 150 may determine thatthere is a service requirement for the tires of the vehicle, and furtheranalyze the sensor data to identify a specific tire requirement, asshown at block 525. For example, the health check system 150 determinesthat one or more of the tires is out of balance, is flat, has degradedtreads, or the like. The health check system 150 accesses validatedsensor data for each of the specific tire related issues, and comparesthe sensor data with the stored data to identify a match.

Similarly, the health check system 150 may determine if the sensor datais indicative of a suspension service requirement, as shown at block 530by comparing sensor data from a subset of sensors associated with thesuspension with predetermined threshold values of the suspension datafor the vehicle 110. If a suspension related service requirement exists,the health check system 150 further analyzes the sensor data bycomparing the sensor data with validated suspension data to identify thespecific suspension issue, as shown at block 535. For example, thehealth check system 150 identifies if the vehicle is operating or adamaged or worn suspension, damaged or worn cradle bushings, or thelike.

Further, the health check system 150 may determine if the sensor data isindicative of a driveline service requirement by comparing the sensordata from a subset of sensors associated with the driveline of thevehicle with predetermined thresholds associated with the performance ofthe driveline, as shown at block 540. If a driveline related servicerequirement exists, the health check system 150 further analyzes thesensor data by comparing the sensor data with validated drivelineperformance data, as shown at block 545. For example, the health checksystem 150 identifies if the vehicle is operating with a drivelineisolation, which may be caused by damaged or worn mounts or bushings.

Further, the health check system 150 determines if the sensor data isindicative of a service requirement by comparing the sensor data from asubset of sensors associated with the powertrain of the vehicle withpredetermined thresholds associated with the performance of thedriveline, as shown at block 550. If a powertrain related servicerequirement exists, the health check system 150 further analyzes thesensor data by comparing the sensor data with validated powertrainperformance data, as shown at block 555. For example, the health checksystem 150 identifies if the vehicle is operating with the powertrainmalfunctioning. It is understood that the health check system 150 canidentify other or additional specific problems with the vehicle 110 thanthose illustrated and described herein. For example, the health checksystem 150 may identify interior noise performance (wind noise or Squeakand Rattle issues etc.) among other problems.

The health check system 150 identifies the specific issue diagnosed inthe notification sent to the notification apparatus 160, as shown atblock 560. In case the health check system 150 is unable to diagnose aspecific problem with the vehicle, the notification apparatus 160 isalerted accordingly.

The signal to the notification apparatus 160 may cause the vehicle tonavigate to a service facility, such as a service facility identified inthe signal. For example, the health check system 150 includes in thenotification a command for an autonomous vehicle to navigate to anidentified service facility. Thus, the health check system 150facilitates determining whether noise and vibration performance sensordata is acceptable for the vehicle 110, and if acceptable thencontinuing use of the vehicle 110; if unacceptable, then returning thevehicle 110 for service in case of an autonomous vehicle. Thenotification, in another example, may be sent to an owner/manager of thevehicle 110, the message indicating that the vehicle 110 requiresservicing in case the vehicle 110 is not autonomous.

The technical solutions described herein facilitate proactivelydiagnosing and servicing a vehicle. The technical solutions may furtherimprove autonomous vehicles where ownership is less likely. As describedherein, the technical solutions facilitate automatically evaluatingnoise and vibration performance of a vehicle and determining if thevehicle is performing at a predetermined level (which may be amanufacturer specific or a customer specific performance level), anddetermining if the vehicle is to be serviced. The technical solutionssend notifications, which may result in an autonomous vehicle beingnavigated to a service facility for servicing or other actions based onthe severity of the measured data in comparison to known performancedata. The technical solutions facilitate identifying degradation inperformance and identifying the service requirements of the vehiclebased on evaluation of noise and vibration data from sensors equippedinside/outside of the vehicle cabin. The system accumulates road noisevibration levels, wind noise levels, powertrain/chassis noise andvibration levels, and the like.

The technical solutions accordingly provide autonomous monitoring of thehealth of the vehicle, before an owner/manager/occupant of the vehiclecomplains or identifies a degraded performance of the vehicle based onnoise and vibration or before a component fails to the extent that thefailure becomes a safety issue for the occupants of the vehicle 110. Thetechnical solutions thus facilitate providing a consistentcustomer-to-vehicle experience by avoiding customer exposure to degradedperforming vehicles. Accordingly, the technical solutions describedherein facilitate monitoring noise and vibrations associated with avehicle, and diagnosing performance of a vehicle independent of acustomer or occupant of the vehicle. The technical solutions furtherimprove the maintenance of the vehicle by eliminating the need for ahuman machine interface to assess the performance of the vehicle.

In case of autonomous fleet applications, the technical solutionsdescribed herein facilitate a consistent customer experiences withvehicle noise and vibration performance. For example, an owner/managerof a fleet of vehicles may configure uniform or common (that isidentical) predetermined performance levels for each of the vehicles inthe fleet. Accordingly, a customer of the fleet experiences a uniformnoise vibration performance irrespective of the vehicle the customerreceives from the fleet. The technical solutions described herein mayuse sensors that are already equipped on the vehicle. Alternatively orin addition, sensors may be added to the vehicle at specific locations,such as seat track, pedals, mirrors, steering wheel, and otherlocations, which may be adjacent to where occupants are seated in thevehicle.

In summary, the technical solutions facilitate a proactive diagnosis anddetection of noise and vibration performance issues before a passengerof the vehicle is exposed to a degraded performance. The technicalsolutions thus facilitate keeping customer experiences with the vehiclepositive and consistent, and moreover safe.

The present technical solutions may comprise a system, a method, and/ora computer program product at any possible technical detail level ofintegration. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent technical solutions.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, but is not limitedto, an electronic storage device, a magnetic storage device, an opticalstorage device, an electromagnetic storage device, a semiconductorstorage device, or any suitable combination of the foregoing. Anon-exhaustive list of more specific examples of the computer readablestorage medium includes the following: a portable computer diskette, ahard disk, a random access memory (RAM), a read-only memory (ROM), anerasable programmable read-only memory (EPROM or Flash memory), a staticrandom access memory (SRAM), a portable compact disc read-only memory(CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk,a mechanically encoded device such as punch-cards or raised structuresin a groove having instructions recorded thereon, and any suitablecombination of the foregoing. A computer readable storage medium, asused herein, is not to be construed as being transitory signals per se,such as radio waves or other freely propagating electromagnetic waves,electromagnetic waves propagating through a waveguide or othertransmission media (e.g., light pulses passing through a fiber-opticcable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, such as example, the Internet, a local areanetwork, a wide area network and/or a wireless network. The network maycomprise copper transmission cables, optical transmission fibers,wireless transmission, routers, firewalls, switches, gateway computers,and/or edge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present technical solutions may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present technicalsolutions.

Aspects of the present technical solutions are described herein withreference to flowchart illustrations and/or block diagrams of methods,apparatus (systems), and computer program products according toembodiments of the technical solutions. It will be understood that eachblock of the flowchart illustrations and/or block diagrams, andcombinations of blocks in the flowchart illustrations and/or blockdiagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present technical solutions. In this regard, eachblock in the flowchart or block diagrams may represent a module,segment, or portion of instructions, which comprises one or moreexecutable instructions for implementing the specified logicalfunction(s). In some alternative implementations, the functions noted inthe blocks may occur out of the order noted in the figures. For example,two blocks shown in succession, in fact, may be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts or carry outcombinations of special purpose hardware and computer instructions.

A second action may be said to be “in response to” a first actionindependent of whether the second action results directly or indirectlyfrom the first action. The second action may occur at a substantiallylater time than the first action and still be in response to the firstaction. Similarly, the second action may be said to be in response tothe first action even if intervening actions take place between thefirst action and the second action, and even if one or more of theintervening actions directly cause the second action to be performed.For example, a second action may be in response to a first action if thefirst action sets a flag and a third action later initiates the secondaction whenever the flag is set.

To clarify the use of and to hereby provide notice to the public, thephrases “at least one of <A>, <B>, . . . and <N>” or “at least one of<A>, <B>, . . . <N>, or combinations thereof” or “<A>, <B>, . . . and/or<N>” are to be construed in the broadest sense, superseding any otherimplied definitions hereinbefore or hereinafter unless expresslyasserted to the contrary, to mean one or more elements selected from thegroup comprising A, B, . . . and N. In other words, the phrases mean anycombination of one or more of the elements A, B, or N including any oneelement alone or the one element in combination with one or more of theother elements which may also include, in combination, additionalelements not listed.

It will also be appreciated that any module, unit, component, server,computer, terminal or device exemplified herein that executesinstructions may include or otherwise have access to computer readablemedia such as storage media, computer storage media, or data storagedevices (removable and/or non-removable) such as, for example, magneticdisks, optical disks, or tape. Computer storage media may includevolatile and non-volatile, removable and non-removable media implementedin any method or technology for storage of information, such as computerreadable instructions, data structures, program modules, or other data.Such computer storage media may be part of the device or accessible orconnectable thereto. Any application or module herein described may beimplemented using computer readable/executable instructions that may bestored or otherwise held by such computer readable media.

While the invention has been described with reference to exemplaryembodiments, it will be understood by those skilled in the art thatvarious changes may be made and equivalents may be substituted forelements thereof without departing from the scope of the invention. Inaddition, many modifications may be made to adapt a particular situationor material to the teachings of the invention without departing from theessential scope thereof. Therefore, it is intended that the inventionnot be limited to the particular embodiments disclosed, but that theinvention will include all embodiments falling within the scope of theapplication.

What is claimed is:
 1. A computer-implemented method for autonomouslymonitoring the health of a vehicle, the computer-implemented methodcomprising: receiving vehicle sensor data comprising at least one fromamong vibration data of the vehicle and noise data of the vehicle,wherein the vibration data comprises measurements of vibrationexperienced by one or more components of the vehicle and the noise datacomprises measurements of sound pressure levels associated with thevehicle, the vehicle sensor data received from a first set of sensors inthe vehicle; accessing vehicle performance data comprising at least onefrom among predetermined vibration performance data of the vehicle andpredetermined noise performance data of the vehicle, the vehicleperformance data collected over a predetermined period of time;determining a difference in the received vehicle sensor data and thepredetermined vehicle performance data; in response to the differencebeing indicative of a performance degradation: autonomously diagnosingthe health of the vehicle by comparing component sensor data associatedwith one or more components to determine a cause of the difference basedon a pattern of the received vehicle sensor data, the autonomousdiagnosing comprising: requesting and receiving component sensor datafrom a second set of sensors that is associated with a specificcomponent; and determining a performance degradation of the specificcomponent by comparing the component sensor data with predeterminedcomponent performance data; and transmitting a notification to anautonomous vehicle controller associated with the vehicle to navigatethe vehicle in response to a diagnosis of the performance degradation ofthe specific component.
 2. The computer-implemented method of claim 1,wherein the vibration data comprises measurements from a vibrationsensor mounted in communication with a seat track of the vehicle.
 3. Thecomputer-implemented method of claim 1, wherein the vibration datacomprises measurements from a vibration sensor mounted in communicationwith one of steering wheel and a steering column of the vehicle.
 4. Thecomputer-implemented method of claim 1, further comprising detecting atire condition based on the determined difference, wherein thepredetermined vibration performance data comprises validated vibrationdata.
 5. The computer-implemented method of claim 1, further comprisingdetecting a powertrain condition based on the determined difference,wherein the predetermined vibration performance data comprises validatedpowertrain vibration data.
 6. The computer-implemented method of claim1, wherein accessing the predetermined vibration performance datacomprises: determining a type of the vehicle; and accessing thepredetermined vibration performance data associated with the determinedtype of the vehicle.
 7. The computer-implemented method of claim 6,wherein the type of the vehicle is determined based on a vehicleidentifier associated with the vehicle.
 8. The computer-implementedmethod of claim 1, wherein the notification commands the autonomousvehicle controller to navigate the vehicle to a service facility.
 9. Thecomputer-implemented method of claim 1, wherein the noise data comprisesmeasurements from a microphone mounted in communication with a seattrack of the vehicle.
 10. An apparatus for autonomously monitoring thehealth of a vehicle, the apparatus comprising: a memory; a communicationinterface; and a processor communicably coupled with the memory and thecommunication interface, wherein the processor is further configured to:receive vibration data of the vehicle, wherein the vibration datacomprises measurement of vibration of one or more components of thevehicle, the vibration data received from a first set of sensors in thevehicle; access a predetermined vibration performance data of thevehicle; determine a difference in the received vibration data and thepredetermined vibration performance data; in response to the differencebeing indicative of a performance degradation: autonomously diagnosingthe health of the vehicle by comparing component sensor data associatedwith one or more components to determine a cause of the difference basedon a pattern of the received vibration data, wherein for the autonomousdiagnosis the processor is configured to: request and receive componentvibration data from a second set of sensors that is associated with aspecific component; and determine a performance degradation of thespecific component by comparing the component vibration data withpredetermined component vibration performance data; and transmit anotification to an autonomous vehicle controller associated with thevehicle to navigate the vehicle in response to a diagnosis of theperformance degradation of the specific component.
 11. The apparatus ofclaim 10, wherein the vibration data comprises measurements from avibration sensor mounted in communication with a seat track of thevehicle.
 12. The apparatus of claim 10, wherein the vibration datacomprises measurements from a vibration sensor mounted in communicationwith a suspension of the vehicle.
 13. The apparatus of claim 10, whereinthe processor is further configured to detect a driveline malfunctionbased on the determined difference, wherein the predetermined vibrationperformance data comprises validated driveline vibration data.
 14. Theapparatus of claim 10, wherein the predetermined vibration performancedata is accessed based on a type of the vehicle.
 15. The apparatus ofclaim 10, wherein the difference is a first difference, and theprocessor is further configured to: receive noise data of the vehicle,wherein the noise data comprises measurements of noise experienced by anoccupant of the vehicle; access a predetermined noise performance dataof the vehicle; determine a second difference in the received noise dataand the predetermined noise performance data; and transmit thenotification in response to the first difference being indicative of theperformance degradation, and the second difference being indicative ofthe performance degradation.
 16. A computer-program product forautonomously monitoring the health of a vehicle, the computer programproduct comprising a non-transitory computer readable storage medium,the computer readable storage medium comprising computer executableinstructions, wherein the computer readable storage medium comprisesinstructions to: receive vibration data of the vehicle, wherein thevibration data comprises measurement of vibration experienced by anoccupant of the vehicle; access a predetermined vibration performancedata of the vehicle; determine a difference in the received vibrationdata and the predetermined vibration performance data; in response tothe difference being indicative of a performance degradation:autonomously diagnose the health of the vehicle by comparing componentsensor data associated with one or more components to determine a causeof the difference based on a pattern of the received vibration data, theautonomous diagnosing comprising instructions to: request and receivecomponent vibration data from a second set of sensors that is associatedwith specific component; and determine a performance degradation of thespecific component by comparing the component vibration data withpredetermined component vibration performance data; and transmit anotification to an autonomous vehicle controller associated with thevehicle to navigate the vehicle in response to a diagnosis of theperformance degradation of the specific component.
 17. Thecomputer-program product of claim 16, wherein the vibration datacomprises measurements from a vibration sensor and a speed of thevehicle at which the measurements are recorded.
 18. The computer-programproduct of claim 16, wherein the difference is a first difference, andthe computer readable storage medium further comprises instructions to:receive noise data of the vehicle, wherein the noise data comprisesmeasurement of noise experienced by an occupant of the vehicle; access apredetermined noise performance data of the vehicle; determine a seconddifference in the received noise data and the predetermined noiseperformance data; and transmit the notification in response to the firstdifference being indicative of the performance degradation, and thesecond difference being indicative of the performance degradation. 19.The computer-program product of claim 18, wherein the noise datacomprises noise measurements captured by a sound pressure levelmeasurement device located inside the vehicle.
 20. The computer-programproduct of claim 18, wherein the noise data comprises noise measurementscaptured by a sound pressure level measurement device located outsidethe vehicle.